There has been an increasing use of mobility management systems that utilize a client/server approach to mobility management of hosts that are coupled to the system. One goal of these systems is to provide a solution for seamless mobility on a network such as, for instance, the global Internet or a private network, that is scalable, robust and secure, and that allows roaming hosts or “mobile nodes” (also referred to herein as “mobile clients”) such as, for instance, radios, phones, laptops, PDAs, etc., to maintain ongoing communications while changing their point of attachment to the network. Specifically, each mobile node is always identified by its home address (regardless of its current point of attachment to the network), which provides information about its point of attachment to a home network. However, when the mobile node is connected to the network outside of its home network, i.e. when visiting a foreign network or a foreign domain, the mobile node is also associated with a care-of address that provides information about its current point of attachment. Those of ordinary skill in the art should realize that the term “care-of address” is not meant to be limited to any particular client/server mobility mechanism but covers other terms used in the art that describe a topologically correct address such as, for instance, a “point-of-presence address.”
Typically, such systems include a plurality of mobility servers and edge mobility agents that utilize a protocol for facilitating the mobility management of the mobile nodes. The mobility server is an entity, for instance a router, on the mobile node's home network that tunnels datagrams (also known in the art as data packets) for delivery to the mobile node when it is away from home, and maintains current location information for the mobile node. The edge mobility agent is an entity, for instance a router, on the mobile node's visited network that provides routing services to the mobile node when the mobile node is registered with the edge mobility agent.
A mobile internet protocol (“mobile IP”) enabled system is one well known example in the art of a mobility management system. Mobile IP provides for a registration process for registering a care-of address with a mobility server called a home agent (“HA”) whose point of attachment, i.e., its IP address, is in the mobile node's home network. The home agent registration is what enables the home agent to send the datagrams destined for the mobile node, i.e., outbound datagrams, through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node.
Registration may, for instance, be facilitated by an edge mobility agent called a foreign agent (“FA”) whose point of attachment is in the visited network and whose IP address is the care-of address for the mobile node. The foreign agent de-tunnels and delivers datagrams to the mobile node that were tunneled by the mobile node's home agent. For datagrams sent by the mobile node, i.e., inbound datagrams, the foreign agent may serve as a default router for registered mobile nodes. The mobile node may, alternatively, obtain a co-located care-of address from the visited network and register that care-of address with its home agent. A foreign agent may or may not be present in the visited network. Even in the presence of a foreign agent, the registration may or may not go through the foreign agent on the visited network when the mobile node is operating with a co-located care-of address.
In accordance with standard mobile IP (defined herein as the implementation of mobile IP in accordance with Request for Comment (“RFC”) 3344, i.e., MPv4), after a mobile node registers its care-of address for a foreign network with its home agent, outbound datagrams are always routed through its home agent to the care-of address. Thus, the source and destination IP address in the datagram are topologically correct because the endpoints of this forward tunnel (i.e., the home agent address and the care-of address) are properly assigned addresses for their respective locations. However, this is typically not the case for inbound datagrams. In accordance with standard mobile IP, inbound datagrams are typically sent to their destination using standard mobile IP based upon the destination address in the datagram header, i.e., not by source address. The source and destination IP address are topically incorrect in this case since the source IP address of a packet transmitted by the mobile node (i.e., the mobile node's home address) does not correspond to the network prefix from where it emanates.
Many routers today implement security policies such as “ingress filtering” that do not allow forwarding of packets that have a source address that appears topologically incorrect. In such environments, mobile nodes may use reverse tunneling with, for instance, the foreign agent supplied care-of-address as the source address. The reverse tunnel then starts at the mobile node's care-of address and terminates at the home agent, wherein it is then forwarded using standard mobile IP to the destination IP address. Thus, when reverse tunneling is used, both inbound and outbound datagrams go through the mobile node's home agent.
When reverse tunneling is used, it may, however, be a shortcoming to have all of the datagrams go through the mobile node's home agent. There may be some situations where peer-to-peer communications (i.e., wherein datagrams are not routed through a mobile node's home agent) may be desired when reverse tunneling is being implemented so as to prevent datagrams from been routed along paths that are significantly longer than optimal. For example, if a mobile node is visiting some subnet, even datagrams from another mobile node on the same subnet must be routed through the mobile node's home agent (on its home network), only then to be tunneled back to the original subnet for final delivery. This indirect routing delays the delivery of the datagrams to mobile nodes, and places an unnecessary burden on the networks and routers along their paths.
One way known in the art of implementing peer-to-peer communication when reverse tunneling is implemented is through route optimization. Route optimization provides a means for a correspondent node to maintain a binding cache containing the care-of address of one or more mobile nodes. When sending a datagram to a mobile node, if the sender has a binding cache entry for the destination mobile node, it may tunnel the datagram directly to the care-of address indicated in the cached mobility binding. In the absence of any binding cache entry, datagrams destined for a mobile node will be routed to the mobile node's home network and then tunneled to the mobile node's care-of address by the mobile node's home agent in accordance with standard mobile IP.
One shortcoming of route optimization is that it addresses only datagrams sent from a fixed correspondent node to a mobile node, and does not facilitate mobile node to mobile node routing. Another shortcoming of route optimization is that it requires changes to both the mobile and correspondent nodes. It is, however, unrealistic to expect all mobile and correspondent nodes to have support for this route optimization feature. Accordingly, many standard mobile IP nodes will not benefit by route optimization.
There is also known in the art a means for bi-directional route optimization. This solution teaches performing route optimization without requiring any change to correspondent nodes by using an entity known as a correspondent agent. However, this solution only addresses route optimization based on the home addresses of the correspondent nodes, which makes it beneficial only when the correspondent nodes are fixed. For correspondent nodes that are mobile, any routing done based on the home address is of no use, since packets are only going to be forwarded to the home network of that node.
Thus, there exists a need for a method for one mobile node to tunnel datagrams to a second mobile node, for instance on the same subnet, without the need for the datagrams to be first sent to the mobile node's home agent. It is further desirable that the solution be compatible with mobile IP.